Please address the comments from this code review:

## Overall Comments
- The new `findContactByIdentifier` method contains several near-duplicate response-shape checks (`contact.data.payload`, `contact.payload`, `contactByAttr.payload`, `contactByAttr.data.payload`); consider centralizing this into a small helper that normalizes a Chatwoot response to a single `payload` array to reduce branching and future maintenance overhead.
- In `getNumberFromRemoteJid`, the function now guards against falsy input but the signature still declares `remoteJid: string`; it would be clearer to either widen the type (e.g., `string | null | undefined`) or move the null/undefined handling to the call sites so the type matches actual expectations.
- The repeated inline logic for deriving `rawPhoneNumber` from `body.key` in ChatwootService (checking `addressingMode === 'lid'`, `fromMe`, `participantAlt`, etc.) would be easier to reason about and less error-prone if factored into a shared helper that encapsulates the JID-to-phone extraction rules in one place.

## Individual Comments

### Comment 1
<location> `src/api/integrations/chatbot/chatwoot/services/chatwoot.service.ts:349-351` </location>
<code_context>

       return contact;
     } catch (error) {
+      if (
+        (error.status === 422 || error.response?.status === 422) &&
+        (error.message?.includes('taken') || error.response?.data?.message?.includes('taken')) &&
+        jid
+      ) {
</code_context>

<issue_to_address>
**issue (bug_risk):** Relying on `'taken'` substring in the error message is brittle and may misclassify errors.

This 422 path depends on `error.message?.includes('taken')` / `error.response?.data?.message?.includes('taken')`, which tightly couples behavior to a particular English string from Chatwoot. That can silently break with localization, wording changes, or different 422 variants. Prefer branching on a structured signal from Chatwoot (e.g., error code, attribute, or a specific payload field). If that’s not available, at least narrow this condition (e.g., to cases where the failing field is the identifier/email) so unrelated 422s containing the word `taken` don’t incorrectly hit this path.
</issue_to_address>

### Comment 2
<location> `src/api/integrations/chatbot/chatwoot/services/chatwoot.service.ts:2534-2538` </location>
<code_context>
   }

   public getNumberFromRemoteJid(remoteJid: string) {
-    return remoteJid.replace(/:\d+/, '').split('@')[0];
+    if (!remoteJid) {
+      return '';
+    }
+    return remoteJid.replace(/:\d+/, '').replace('@s.whatsapp.net', '').replace('@g.us', '').replace('@lid', '');
   }

</code_context>

<issue_to_address>
**issue:** The new `getNumberFromRemoteJid` implementation may fail to strip unknown JID suffixes and changes behavior for some inputs.

The previous `.split('@')[0]` stripped any suffix; the new version only handles three specific ones, so JIDs like `@broadcast` or future/custom domains will now include the suffix in the "number", which may break callers expecting a pure phone number. You could keep the generic stripping while still handling the numeric resource explicitly, e.g.:

```ts
if (!remoteJid) return '';
const cleaned = remoteJid.replace(/:\d+/, '');
return cleaned.split('@')[0];
```

or apply your specific replacements first and then still `split('@')[0]` as a final safeguard. Also, returning `''` instead of `undefined`/`null` for falsy `remoteJid` changes the function’s contract, so it’s worth checking existing callers for assumptions about that value.
</issue_to_address>

### Comment 3
<location> `src/api/integrations/channel/whatsapp/whatsapp.baileys.service.ts:1616-1620` </location>
<code_context>

       // Helper to normalize participantId as phone number
-      const normalizePhoneNumber = (id: string): string => {
+      const normalizePhoneNumber = (id: string | any): string => {
         // Remove @lid, @s.whatsapp.net suffixes and extract just the number part
-        return id.split('@')[0];
+        return String(id || '').split('@')[0];
       };

</code_context>

<issue_to_address>
**suggestion:** The `normalizePhoneNumber` parameter type `string | any` is misleading and undermines type safety.

Since the implementation already does `String(id || '')`, the function is designed to handle non-string/nullable inputs. Typing the parameter as `string | any` collapses to `any` and removes useful type checking. Use a more accurate type such as `id: string | null | undefined` (or `unknown` if you truly expect arbitrary values) so call sites are still type-checked while your runtime fallback remains valid.

```suggestion
      // Helper to normalize participantId as phone number
      const normalizePhoneNumber = (id: string | null | undefined): string => {
        // Remove @lid, @s.whatsapp.net suffixes and extract just the number part
        return String(id || '').split('@')[0];
      };
```
</issue_to_address>